Overview

Tài liệu này cung cấp tổng quan về kiến trúc hệ thống của Gcalls. Nhằm truyền đạt các kiến trúc được sử dụng trong hệ thống giúp người đọc nắm được tổng quan về hệ thống Gcalls.

I. Service Overview

Trong kiến trúc gcalls các service được chia thành các lớp:

• Gcalls Front:

  • contactApp (webphone-service)
    • Webapp cho phép người dùng quản lý, thống kê các thông tin về danh bạ. Webapp cũng cung cấp tích hợp callbox, tích hợp CRM.
  • Callbox
    • Callbox được sử dụng với các tích hợp CRM giúp người dùng có thể nghe gọi và tương tác dữ liệu khách hàng với hệ thống CRM tích hợp.
  • portalApp (portal-service)
    • Portal là trang quản lý nội bộ của Gcalls giúp quản lý thông tin và cấu hình về tổng đài, gói dịch vụ, tích hợp, api, record PBX,...

• Gcalls Middle:

  • accessService
    • Access Service đảm nhận vai trò như một api gateway của hệ thống giúp tiếp nhận và điều hướng api.
    • Access Service cũng cung cấp một số cronjob để xử lý thông tin activity như:
      • Gộp Log
      • Reminder
  • apiService (api management)
    • Api Service cung cấp một số API cố định để khách hàng có thể tích hợp và tương tác với dữ liệu của mình ở Gcalls.
  • integrateService (integration manager)
    • Integrate Service đảm nhận vai trò tương tác chính với api của các tích hợp bên ngoài.
    • Mọi yêu cầu tương tác tích hợp đều được gửi đến và được Integrate Service tiếp nhận và xử lý.
    • Integrate Service cung cấp một số cronjob về tích hợp như:
      • Refresh Token
      • Log System
  • mobileService
    • Mobile Service đảm nhận vai trò như một backend của Callbox. Mobile Service tiếp nhận các yêu cầu từ callbox, xử lý và chuyển hướng đến Access Service và Integrate Service.
  • rawsService (log service)
    • rawsService giúp tiếp nhận các thay đổi của couchdb được gửi từ Logstash để xử lý và thêm vào hệ thống Gcalls.
    • rawsService còn đảm nhận vai trò như một webhook có trách nhiệm xử lý log system, callrate, các log nhận được từ PBX Server.
  • streamService (pbx-log service)
    • streamService đang được sử dụng để xử lý dữ liệu từ Gcalls giúp Google Data Studio visualize data.
  • webService
    • Web Service đảm nhận vai trò như một backend của contactApp. Web Service tiếp nhận các yêu cầu từ contactApp, xử lý và chuyển hướng đến Access Service.

• Gcalls Back:

  • commandService

    • commandService tiếp nhận và xử lý các yêu cầu ghi dữ liệu đến các database kết nối bao gồm:
    • customer kết nối với database customer-service giúp xử lý các yêu cầu ghi đến database.
    • user kết nối với database user-service giúp xử lý các yêu cầu ghi đến database.
    • thirdParty kết nối với database third-party-service giúp xử lý các yêu cầu ghi đến database.

  • recordService

    • recordService kết nối với database record-service giúp xử lý các yêu cầu ghi đến database và các yêu cầu lấy ghi âm của client.
    • recordService cung cấp một số cronjob giúp xử lý record:
      • Daily Sync Record.
      • Monthly Record.

  • filterService

    • filterService được kết nối tới toàn bộ database của hệ thống.
    • filterService tiếp nhận và xử lý toàn bộ các yêu cầu query dữ liệu đến các database kết nối.

• Gcalls DB:

  • MongoDB
    • Database chính chứa phần lớn dữ liệu của hệ thống.
    • MongoDB được triển khai theo mô hình replica set.
  • CouchDB
    • Database tạm thời chứa thông tin calllog của hệ thống.
    • Data ở đây sẽ được xóa đi nếu thành công lư trữ vào MongoDB
  • PostgreSQL
    • Database của keycloak chứa thông tin user và tenant.
  • Redis
    • Redis đảm nhận vai trò cache các dữ liệu ít thay đổi giúp tăng tốc độ hệ thống.
    • Redis Pub/Sub đóng vai trò kết nối giữa WebPhone Service, Mobile Service và Access Service giúp xử lý một số tính năng realtime.

• Gcalls Stack:

  • Keycloak
    • Keycloak đóng vai trò quản lý session đăng nhập của hệ thống, các vấn đề liên quan đến đăng nhập, user session được quản lý ở đây.
  • Logstash
    • Logstash đảm nhận vai trò lắng nghe các thay đổi từ couchdb và gửi nó đến rawsService để xử lý.

II. Deployment Techniques

1. Blue - Green

Webphone Service hiện được deploy theo mô hình Blue - Green, ở mô hình này Webphone Service sẽ được deploy 2 phiên bản ở 2 server khác nhau và được routing trên cùng domain:

• Blue ( /b )

  Ở phiên bản Blue Webphone Service được deploy với các tính năng, chỉnh sửa mới nhất.

• Green ( /g )

  Phiên bản Green là phiên bản chính thức và ổn định của Webphone Service với các tính được kiểm thử và hoạt động ổn định trong một thời gian nhất định.

2. Feature Flag / Feature Rollout

Webphone Service đang áp dụng kỹ thuật feature flag cho phép developer thay đổi cách hoạt động của ứng dụng, mà không cần phải sửa code

Feature flag được áp dụng để release các tính năng mới và rollout các tính năng cho các template, user role khác nhau.

III. Infrastructure Design

1. Microservice

Ở mô hình micro service các service đặc trên các server riêng biệt giúp dễ dàng để nâng cấp và scale ứng dụng.

Ở mô hình này mỗi write service được kết nối tới một database của riêng nó.

2. Single Server

Trong một số trường hợp đặc biệt như môi trường dev hoặc deploy trên demo server. Để tiết kiệm tài nguyên ta có thể deploy tất cả các service trên 1 server duy nhất

3. High Availability Cluster

Trong môi trường production có thể áp dụng kiến trúc cluster. Giúp hệ thống luôn trong tình trạng sẵn sàng phục vụ, giảm thiểu khả năng gián đoạn của hệ thống.

Cluster là việc kết hợp nhiều phần cứng riêng lẻ thành một cụm để cung cấp dịch vụ.

Mô hình naỳ có 2 phương thức hoạt động chính là:

• Active - Active
• Active - Passive

Kết Luận

Trên đây là tổng quan về kiến trúc hệ thống Gcalls. Nếu có câu hỏi nào vui lòng điền vào form bên dưới.